A UDP (User Datagram Protocol) and a RTP (Real-time Transport Protocol) have been used as a protocol when AV (Audio/Visual) transmission is performed on an intranet connected to the internet and a VPN (Virtual Private Network). The use of the UDP is preferred for the following two reasons. The first reason is that totally depending on an upper-level protocol for packet delivery guarantee makes it possible to realize a light-load transmission and reception process. The second reason is that the delivery guarantee by a retransmission process, which is the main purpose in the use of a TCP (Transmission Control Protocol), inversely becomes a drawback in application where delay of real time reproduction and so on is viewed as a problem.
In real time AV reproduction, when data that does not arrive by a specified time is detected, performing an error concealment process with a reception player minimizes an impact of data loss, and a packet itself is not retransmitted. However, when an impact of network congestion causes packets to be frequently missed, sufficient reproduction quality cannot be guaranteed with the error concealment process. As a result, the following method is used: 1) periodically feeding back a reception status from a reception side to a transmission side; and 2) dynamically adjusting a transmission rate at the transmission side.
RTP (refer to Non-patent References 1 and 2, for example) is a protocol for dividing AV data coded according to, for instance, MPEG (Moving Picture Experts Group) standard into packets and for transmitting the packets. RTP serves to transport packet sequence information necessary for intramedia synchronization and time synchronization information necessary for intermedia synchronization. In addition, RTCP (RTP Control Protocol), which is specified as a part of RTP, serves to feed back quality information gathered at the reception side to the transmission side, and is used for 1). As examples of 2), there are RealMedia™ of RealNetworks, Inc., WindowsMedia™ of Microsoft Corporation, and QuickTime™ of Apple Inc. SureStream in RealMedia™ dynamically switches a coding rate by performing scalable coding with single resolution, depending on a situation at a reception side. Intelligent Streaming of WindowsMedia™ and QTSS optimize a transmission rate by performing adjustment with thinning based on reception quality fed back. Because these schemes using the feedback of the reception quality with RTCP are an end-to-end process, there is a chance that adaptability becomes a problem.
Packet loss occurs at a relay device such as a switch and a router on a path from a source communication device (transmission device) to a destination communication device (reception device). In addition, the packet loss occurs because a rate difference between link layers and concentration of traffics cause a backlog to exceed tolerance. The backlog is a packet that is stacked up in the relay device and is waiting to be relayed. A timing at which the packet loss is detected in the relay device is after all the packets waiting to be relayed are delivered. For this reason, a time lag depending on the length of the backlog impairs the adaptability. A lag of a timing for controlling a transmission rate prevents a traffic status from being adjusted to a status of a temporarily variable network. This inversely worsens a degree of congestion at the relay device and disrupts the stability of the whole system, which causes danger of inviting congestion collapse. In response, Patent Reference 1 discloses a method for improving adaptability by actively checking a status of the relay device at the transmission side.
FIG. 30 is a diagram showing a structure of a system disclosed by Patent Reference 1. The system includes a transmission device 201, relay devices 202 to 204, and a reception device 205, each of which is connected to a network. The system actively gathers a parameter pertaining to an internal status of each of the relay devices 202 to 204 by causing the transmission device 201 to send a probe packet to the relay device. The first probe packet in the figure is a probe packet for gathering a status of the relay device 202, and similarly the second probe packet and the third probe packet are probe packets for gathering statuses of the relay devices 203 and 204, respectively. An example of the parameter to be gathered includes, for instance, an inter-device RTT (round-trip time) or a LOSS (packet loss rate).
RTT on an IP network is measured by using a protocol called ICMP (Internet Control Message Protocol). In other words, a source transmission device transmits a packet called an ICMP Echo Request shown in FIG. 31 to a destination relay device, and at the same time records a sequence number SEQNUM and a transmission time. A reception device having received the ICMP Echo Request duplicates contents of ID, SEQNUM, and DATA stored in the request packet into fields of ID, SEQNUM, and DATA of a reply packet. Subsequently, the reception device sends back the reply packet as an ICMP Echo Reply. The transmission device having received reply data can obtain a transmission time of request data corresponding to the received reply by referring to the content of SEQNUM. Moreover, the RTT is obtained by calculating a difference between the transmission times. Actually, the RTT is often calculated, as an average value in a given amount of time, by continuously transmitting probe packets, so as to improve accuracy. Furthermore, the LOSS is obtained as a ratio of sending back the ICMP Echo Reply to each of transmitted ICMP Echo Requests. A ping is known as a program for performing a series of such operations.
In an example shown in FIG. 31, a given data sequence is stored in DATA. As shown in FIG. 32, however, a time stamp at the time of issuing the ICMP Echo Request is stored into a packet depending on implementation of the ping. In this case, RTT at the time of receiving a reply is calculated when the relay device echoes back the value. Patent Reference 2 describes an example of calculating RTT using a time stamp. Because the RTT and the LOSS vary according to a processing time in the relay device, it is possible to determine an appropriate transmission rate based on the information.
Patent Reference 1 discloses a method for estimating the number of packets stacked up in the relay device based on a link band of each of relay devices and a time change of RTT and for adjusting a rate to a bottleneck under the most loaded condition. With this method, because the transmission rate is controlled at a transmission device side based on a loaded condition estimated from a reply rate of the relay device, which is included in the measured RTT, adaptability is improved as much as a reception device is not involved. Furthermore, Non-patent Reference 3 shows that conversion into an appropriate transmission rate according to Equation 1 is possible using a measured RTT or LOSS of the reception device. In the equation, R is a transmission rate, MTU is transfer unit length on a path, and T0 is a TCP session timeout period.
                    R        =                              M            ⁢                                                  ⁢            T            ⁢                                                  ⁢            U                                                                                                    RTT                    ·                                                                  2                        ·                                                  LOSS                          /                          3                                                                                                      +                                                            T                      0                                        ·                                          (                                              3                        ⁢                                                                              3                            ·                                                          LOSS                              /                              8                                                                                                                          )                                                                                                                                            LOSS                  ·                                      (                                          1                      +                                              32                        ·                                                  LOSS                          2                                                                                      )                                                                                                          [                  Equation          ⁢                                          ⁢          1                ]            Non-patent Reference 1: IETF RFC3550 RTP: A Transport Protocol for Real-Time ApplicationsNon-patent Reference 2: IETF RFC2250 RTP Payload Format for MPEG1/MPEG2 VideoNon-patent Reference 3: IETF RFC3448 TCP Friendly Rate Control (TFRC)Patent Reference 1: Japanese Patent No. 3662907Patent Reference 2: Japanese Unexamined Patent Application Publication No. 5-260090Patent Reference 3: Japanese Patent No. 3588570